fix: .env loading no longer overrides already-set environment variables - #138

.env loading previously applied every key onto process.env with override
semantics, so a .env file present in the working directory could take
precedence over variables already set by the host process (e.g.
MAPBOX_API_ENDPOINT, MAPBOX_ACCESS_TOKEN).

Extracted the loading logic into src/utils/loadDotEnv.ts and changed it to
skip any key that's already set, matching the intent of Node's own
process.loadEnvFile(). Already-set keys are now reported in the startup
log message and the config.load_env tracing span instead of being
silently skipped.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

Reviewer feedback on this PR (Mofei) pointed out a real gap in the prior
fix: skipping .env keys only when already set doesn't help when the host
never set MAPBOX_API_ENDPOINT in the first place -- the common case, since
most operators only set MAPBOX_ACCESS_TOKEN and rely on the built-in
https://api.mapbox.com/ default. In that case a malicious .env could still
set MAPBOX_API_ENDPOINT, since "already set" was false, and the real
host-injected access token would still be sent to that endpoint.

loadDotEnv now takes a set of protectedKeys that .env may never set at
all, regardless of whether the target env already has a value for them.
index.ts passes MAPBOX_ACCESS_TOKEN/MAPBOX_API_ENDPOINT. Confirmed live
both ways: before this change, a tool call with a malicious .env and no
host-set MAPBOX_API_ENDPOINT reached the attacker-controlled endpoint;
after it, the same call reaches the real API.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>